During provisioning of a virtual machine, one or more virtual memories may be created for use with that virtual machine. These virtual memories may include a virtual cache, a virtual overflow disk, and/or a virtual system disk, each of which may correspond to physical memory resources (e.g., physical disk or memory) of the underlying one or more physical hosts hosting the virtual machine. In many instances, the time taken to provision the virtual machine (e.g., amount of time to start up a virtual machine) may be longer than desired. Much of the boot time of a virtual machine is a result of the virtual machine writing a table of contents (e.g., a map) that accounts for every sector of the various virtual memories to its virtual system disk. In doing so, the hypervisor propagates the write command of the table of contents to an image of the virtual disk reserved for this virtual machine. Since the sector is designed to be of a small size (as it is often the minimum size for a block of memory), there may be millions of sectors that must be accounted for when the virtual machine and hypervisor write the table of contents, which results in an increased lag at boot time of the virtual machine.
Exacerbating the problem, often hundreds or thousands of virtual machines may be booted up within a short time from one another. For example, at the beginning of a workday hundreds of people may request to create a virtual machine of their work computer or other device. Thus, the hypervisor and/or a session manager may have to map the virtual memories for each of the hundreds or thousands of virtual machines being requested within a short time frame from one another. This results in further increased lag time to boot up the virtual machines, which detracts from the overall user/customer experience.
In addition, for an upfront, fixed-size caching mechanism, a table of contents mapping virtual memory may use a large amount of memory space within the virtual memory of a virtual machine. In some cases, it may be at least 6 sectors in size, which is an unnecessarily large amount of space for the table of contents. Further, caching methodologies currently employed by virtual machines to satisfy read requests quickly fill the virtual cache. For instance, if a read block is retrieved from the virtual system disk, the read block is first written to the virtual cache prior to sending the read block to its requester. Once the virtual cache is filled, a virtual overflow disk is utilized by the virtual machine so that blocks in the virtual cache may overflow (e.g., move) from the virtual cache to the virtual overflow disk. As blocks are overflowed from the virtual cache to the virtual overflow disk, the table of contents mapping the virtual disk to the sectors/blocks must be constantly updated resulting in a vast amount of overhead as well as delay in servicing read and write commands, which detracts from the user/customer experience. Yet another issue caused by current virtual machine caching mechanisms is the need to periodically reboot the virtual machine once the overflow disk runs out of storage space.